Mutexy
Otázka od: Jiri Cincura
5. 6. 2004 22:21
Ahoj,
synchronizuju 2 thready pomoci mutexu, ale aby prvni cekal na druhy, musim
vytvorit Mutex. Ale ja bych ho potreboval vytvotit jeste pred nastartvanim 2
threadu, abych mel 100% jistotu, ze mi 2. nepredbehne 1. Ale to nejde, nebot
tohle (busy-waiting) se nezachyti:
while WaitForSingleObject(FreeDB_Mutex, 200) = WAIT_TIMEOUT do
begin
Application.ProcessMessages;
end;
Jedine misto, kam muzu dat:
FreeDB_Mutex := CreateMutex(nil, True, 'FreeDB_Mutex');
je Execute toho threadu, ale to mam problem s tim predbihanim, takze tam mam
takovyto bastl, ktery pocka na vytvoreni
while WaitForSingleObject(FreeDB_Mutex, 200) = WAIT_FAILED do
begin
Application.ProcessMessages;
end;
slo by tam i Sleep(200) treba, ale kdyby to trvalo dele, slo by to do kytek.
Nevi tedy nekdo, jak vytvorit mutex pred nastartovanim 2. threadu, aby mi to
fungovalo? Ve druhem thradu pak udelam CloseHandle a pokracuje se, ale to
vytvoreni je divne. Asi to musi byt "really" z jineho procesu a to je ten
problem.
btw: chtel jsem tam dat kritickou sekci, ale ta nema TimeOut a stejne mi
nejela, sly obe vlakna zaraz.
--
Jiri Cincura
e-mail: mailto:jiri@cincura.net; mailto:xcincura@informatics.muni.cz
ICQ: 314711544
web: http://www.cincura.net; http://cincura.net/photo
Odpovedá: Petr Fejfar
6. 6. 2004 9:21
Jiri Cincura wrote:
> synchronizuju 2 thready pomoci mutexu, ale aby prvni cekal na
> druhy, musim vytvorit Mutex. Ale ja bych ho potreboval vytvotit jeste
> pred nastartvanim 2 threadu, abych mel 100% jistotu, ze mi 2.
> nepredbehne 1. Ale to nejde, nebot tohle (busy-waiting) se nezachyti:
Mel by ses zamyslet nad tim, k cemu vlastne mutexy a kriticke sekce slouzi
a podivat se, jestli bys pro dany typ synchronizace nenasel vhodnejsi
prostredek 
HTH, pf
Odpovedá: Petr Vones
6. 6. 2004 10:54
From: "Jiri Cincura" <jiri@cincura.net>
> je Execute toho threadu, ale to mam problem s tim predbihanim, takze tam mam
> takovyto bastl, ktery pocka na vytvoreni
>
> while WaitForSingleObject(FreeDB_Mutex, 200) = WAIT_FAILED do
> begin
> Application.ProcessMessages;
> end;
Nevolej z aplikace Application.ProcessMessages, a uz vubec ne z jineho nez
hlavniho threadu.
Petr Vones
Odpovedá: Jiri Cincura
6. 6. 2004 11:39
Petr Vones wrote:
>
> Nevolej z aplikace Application.ProcessMessages, a uz vubec ne z
> jineho nez hlavniho threadu.
Ja to volam pouze z hlavniho threadu aplikace. Ceka totiz na dokonceni prace
2. threadu (non main) a chci, aby mi aplikace "reagovala".
Jak mam teda jinak donutit, aby kdyz aplikace "ceka" zpracovala zpravy? A
jak to vubec synchronizovat?
--
Jiri Cincura
e-mail: mailto:jiri@cincura.net; mailto:xcincura@informatics.muni.cz
ICQ: 314711544
web: http://www.cincura.net; http://cincura.net/photo
Odpovedá: Petr Vones
6. 6. 2004 12:08
From: "Jiri Cincura" <jiri@cincura.net>
> Ja to volam pouze z hlavniho threadu aplikace. Ceka totiz na dokonceni prace
> 2. threadu (non main) a chci, aby mi aplikace "reagovala".
Jednoduse, zavolas po dokonceni udalost ktera nastavi nejaky flag (nebo treba
Action) ze se akce dokoncila.
> Jak mam teda jinak donutit, aby kdyz aplikace "ceka" zpracovala zpravy? A
> jak to vubec synchronizovat?
Aplikace (hlavni thread) by nemel nikdy na nic cekat. Ten si vzdy zije svym
zivotem a je predevsim od toho aby obsluhoval uzivatelske rozhrani. Misto toho
by si mel vytvorit logiku aplikace tak, ze definujes stavy ve kterem se prave
nachazi a ty menis napriklad tou udalosti z threadu.
Petr Vones
Odpovedá: Jiri Cincura
6. 6. 2004 12:02
Problem je v tom, ze otevru novy form a ten dela I/O operace (tri HTTP
pozadavky) a to nekdy trva dlouho. Proto jsem ty pozadavky dal do threadu,
abych mohl ten form nechat obsluhovat smycku zprav, ale vysledek tech HTTP
pozadavku potrebuju pro dalsi zpracovani v tom formu. Proto musim cekat, ale
chci, aby ten Form "reagoval".
Nejsem zadnej super expert pres mutli-threading, tak nevim, jak bych to
jinak udelal.
Muzes me teda nakopnout spravnym smerem?
--
Jiri Cincura
e-mail: mailto:jiri@cincura.net; mailto:xcincura@informatics.muni.cz
ICQ: 314711544
web: http://www.cincura.net; http://cincura.net/photo
Odpovedá: Petr Vones
6. 6. 2004 12:26
From: "Jiri Cincura" <jiri@cincura.net>
> Problem je v tom, ze otevru novy form a ten dela I/O operace (tri HTTP
> pozadavky) a to nekdy trva dlouho. Proto jsem ty pozadavky dal do threadu,
> abych mohl ten form nechat obsluhovat smycku zprav, ale vysledek tech HTTP
> pozadavku potrebuju pro dalsi zpracovani v tom formu. Proto musim cekat, ale
> chci, aby ten Form "reagoval".
Stejne tak jako reagujes na stisknuti klavesy, tlacitka mysi, udalost od
timeru budes reagovat i na udalost o zpracovani tech HTTP pozadavku. Windows
jsou (podobne jako byly uz kdysi TurboVision) udalostmi rizene, takze styl
programovani:
Action1;
while WaitingForData do
Wait;
Action2;
je spatny.
Misto toho by si mel definovat stavy:
TAppStatus = (action1, action2);
Rekneme ze status aplikace je action1, v pripade ze prijde udalost od
zpracovani toho pozadavku jej nastavis na action2 a pokracujes. Pri kazde
zmene stavu se provedou potrebne kroky ktere vyplyvaji z logiky aplikace.
Hlavni thread tedy neceka v zadne lokalni smycce, pouze reaguje na udalosti.
Petr Vones
Odpovedá: Jiri Cincura
6. 6. 2004 12:21
Petr Vones wrote:
> TAppStatus = (action1, action2);
>
> Rekneme ze status aplikace je action1, v pripade ze prijde udalost od
> zpracovani toho pozadavku jej nastavis na action2 a pokracujes. Pri
> kazde zmene stavu se provedou potrebne kroky ktere vyplyvaji z logiky
> aplikace. Hlavni thread tedy neceka v zadne lokalni smycce, pouze
> reaguje na udalosti.
Aha, tak to je velice chytre. Je jsem sel cestou nejmensiho odporu a udelal
tam trapny busy-waiting. Jasne pres udalosti to bude asi nejlepsi. Jen to
bude chtit trochu vic usili. 
--
Jiri Cincura
e-mail: mailto:jiri@cincura.net; mailto:xcincura@informatics.muni.cz
ICQ: 314711544
web: http://www.cincura.net; http://cincura.net/photo
Odpovedá: Petr Vones
6. 6. 2004 12:30
From: "Jiri Cincura" <jiri@cincura.net>
> Aha, tak to je velice chytre. Je jsem sel cestou nejmensiho odporu a udelal
> tam trapny busy-waiting. Jasne pres udalosti to bude asi nejlepsi. Jen to
> bude chtit trochu vic usili.
Z pocatku to tak vypada. Ale v drtive vetsine pripadu se to vyplati, protoze
se tak snadneji definuje a predevsim po case pripadne pak upravuje logika cele
aplikace.
Petr Vones